Diameter is an authentication, authorization, and accounting (AAA) protocol for computer networks, and is a successor to Radius. The Diameter base protocol is defined in International Engineering Task Force (IETF) request for comments (RFC) 3588 which is incorporated by reference herein in its entirety. Diameter messages use a per user framework and exist in the format of request-answer messages. Diameter answer messages travel back to the request source via the same path through which the request message was routed using hop-by-hop transport.
Diameter messages may be exchanged between Diameter nodes for performing various functions. For example, a mobility management entity (MME) and a home subscriber server (HSS) may interact for authentication, authorization, and/or accounting (AAA) purposes. Since communications networks use Diameter messages to perform a variety of functions, it is important to make sure that Diameter nodes are working correctly and as expected.
Network resource utilization, or “load”, is a valuable indicator of network conditions and profoundly affects network performance. Load may be expressed as a raw number, such as packets per second, or as percentage of maximum capacity. A telecommunications network has a variety of components, such as communications links, processors, databases, etc. If one component becomes fully loaded, e.g., operating at 100% capacity, or overloaded, e.g., turning away requests for processing because there is no available capacity, the performance of the entire network may suffer, particularly if the overloaded component provides a critical function. Using the world wide web as an example, most web browsers must perform a domain name system (DNS) lookup to translate a universal resource identifier (URI) or universal resource locator (URL) address into an IP address. If the DNS service goes down, web browsing traffic will also grind to a halt because a critical function—the DNS lookup—is unavailable.
Therefore, knowledge of network load is extremely useful and may be used to get a picture of overall network health and to identify existing and potential problems. In this context, the terms “load” and “overload” have somewhat overlapping meanings: for example, a node may be said to be “loaded” when its utilization is between 0% and 100% and “overloaded” when its utilization is greater than 100% percent. In another example, a node that is part of a matched pair of nodes that provide the same function in a distributed manner may be considered “overloaded” if its capacity is greater than 50%, since the other 50% must be reserved for use in case the other node in the pair fails and causes that node's traffic to be handled by the first node. Similarly, if a node reports its utilization as being less than some overload threshold, such as message may be considered a “load indication”, but if the node reports its utilization as being greater than the threshold, such as message may be considered an “overload indication”. In other words, the difference between a “load message” and an “overload message” may be a matter of degree. For simplicity, the terms “load” and “overload” will be used synonymously herein unless explicitly stated otherwise.
Determining network load, however, can be challenging. Determining the load of a segment of a packet network, for example, may require the attachment of monitoring devices or taps to the physical link itself. Determining the load of a network server may be difficult if the server OS does not have the capacity to monitor its own processor load, memory utilization, and so on. Even if the load of a particular entity within the network can be determined, there is still the challenge of conveying that load information to other nodes in the network in a form that the other nodes understand and can use to make decisions or take action to help mitigate a loaded or overloaded component of the network.
Exemplary methods and systems for performing overload control are described in commonly-owned, co-pending U.S. patent application Ser. No. 13/863,351, filed Apr. 15, 2013 (herein referred to as “the '351 application”), the disclosure of which is incorporated herein by reference in its entirety. The '351 application discloses the use of Diameter messages to convey load or overload information using Diameter attribute-value pairs, or “AVPs”, that may be inserted into existing Diameter messages or may be a part of a stand-alone Diameter message for this purpose. A “Load AVP” is an AVP that may report a load or overload condition, and an “Overload AVP” is an AVP that may describe an action to be taken to mitigate an overload condition.
The subject matter described herein describes a different mechanism that may also be used to perform Diameter overload control. More specifically, the subject matter described herein describes methods, systems, and computer readable media for Destination-Host defined overload scope.